═══ 1. Table of Contents ═══ The DCF/2 Online Help covers the following topics. Click on the highlighted topic to get help. o Introduction o Installation o "The Big Picture" o DCF/2 and System Startup o OS/2 File Systems o DCF/2 User Reference o VDU Maintenance & Troubleshooting o Appendix o Glossary ═══ 2. Introduction ═══ The DCF/2 is an "on-the-fly disk compression facility which allows you to increase the effective data storage capacity of your OS/2 computer system. It is unlike the on-the-fly data compression products available to DOS users. Unlike DOS compression products, which require you to have 50 MB of space free in order to create a 100 MB compressed drive -- the compressed drives you create using the DCF/2 grow dynamically. With the DCF/2, when you create a 100MB compressed drive and format it, it occupies less than 350K of physical space. You can create your first "VDU" even if you are down to your last few megabytes of physical space. Unlike DOS compression products, the DCF/2 does not automatically compress the contents of the "host" drive. Instead, you decide what you want to move to compressed storage. As you move your data onto your "VDU", you recover physical space on its "host" drive. Unlike DOS compression products, DCF/2 compressed drives are formatted using OS/2's High Performance File System. With the DCF/2, you can experience the speed and efficiency of this powerful file system without reformatting or repartitioning your existing physical hard drive. Unlike DOS compression products, DCF/2 compressed drives can reside on any device supported under OS/2 -- network and removeable media (read-write opticals, magneto opticals and floppies, etc.) included! Unlike DOS compression products, the DCF/2 is a full 32-bit utility -- designed to grow with your OS/2 desktop. ═══ 2.1. The DCF/2 and OS/2 Version Support ═══ If you have not yet updated your system to OS/2 2.11 (OS/2 2.1 plus the Service Pak), you must do so in order to use the DCF/2 on your HPFS-formatted drives. If for some reason you cannot install OS/2 2.11 on your system, DCF/2 compressed drives must be placed only on non-HPFS "host" drives. The DCF/2 does not support versions of OS/2 prior to OS/2 2.0. To order the Service Pak, call IBM at (800) 494-3044. If you are running OS/2 2.11 and the High Performance File System is installed, but the version is older than the one shipped on the DCF/2 distribution diskette, the DCF/2 installation program will make a backup copy of your existing file and then replace it with the HPFS.IFS dated April 19, 1994. If you are running OS/2 2.11 and the High Performance File System is not currently installed on your system, the DCF/2 install program will install the OS/2 2.1 UHPFS.DLL and the HPFS.IFS dated the April 19, 1994, to the correct directory and will add the HPFS statement to your CONFIG.SYS. If you are running a version of OS/2 after 1.3 but prior to 2.11 and do not have the High Performance File System installed, the DCF/2 installation program will install the OS/2 2.1 GA UHPFS.DLL and HPFS.IFS and insert the HPFS statement in your CONFIG.SYS file. Finally, if you are running a version of OS/2 after 1.3 but prior to 2.11, have the High Performance File System installed and have partitions formatted as HPFS, the DCF/2 installation program will update your HPFS.IFS to the OS/2 2.1 GA version. IN THIS CASE, DO NOT CREATE DCF/2 VIRTUAL DISK UNITS ON YOUR HPFS FORMATTED PARTITIONS -- USE ONLY FAT-BASED HOSTS. The remainder of this introduction will present a few of the basic terms that you will encounter frequently throughout this document. ═══ 2.2. Basic Terms ═══ Installing the DCF/2 is easy. Before you do so, however, you need to have a basic understanding of the terms we use to describe the differences between the three types of storage units [--] physical, logical and virtual. (Sound scary? It's not.) Physical Disk Unit Your hard disk or hard drive is a Physical Disk Unit (PDU). You can reach out and touch it. You use low level utilities like FORMAT and CHKDSK on it. It may have one or more "logical" partitions. Logical Disk Unit A network drive is a Logical Disk Unit (LDU). You cannot reach out and touch it. You cannot perform physical operations on it. You cannot run low level utilities like FORMAT and CHKDSK on it. Virtual Disk Unit A DCF/2 Virtual Disk Unit (VDU) looks like a real, physical disk unit to OS/2. It has real geometry (so many heads, so many sectors per track). You run low level utilities like FORMAT and CHKDSK on it. It does not exist in the physical sense. It "exists" as a "storage container" for your compressed data on either a physical or a logical disk unit. ═══ 3. Installation ═══ The installation process includes creating VDUs, copying the DCF/2 program files to a target directory, updating your CONFIG.SYS file and restarting your system. Note: The DCF/2 Version 1.1b installation program should only be used to install the DCF/2 programs and create your first VDUs. It is not intended to be used to create additional VDUs or to update VDUs created under previous versions of the DCF/2. If you currently have VDUs installed that were created using a previous version of the DCF/2, please refer to the appendix for converting old VDUs to Version 1.1b. Note: Attention network clients: If you use a LAN and the LAN drives letters you use are adjacent to your first physical drive letter, they will have to be moved to after the VDU drive letters. Drive letter swapping is not available in this release, but will be included in a future version of the software. If you have network drives defined, please logoff of the network prior to running the DCF/2 install program. The section on installation covers the following topics: o Choosing the Target Drive o Selecting the Number of VDUs o Creating VDUs o Updating the Configuration o Restarting Your System o Formatting VDUs with AutoFormat o AutoChecking VDUs o Formatted, Clean and Ready for Data o DCF/2 OS/2 System Shutdown Program o Installing from a Network Server o Updating Workstation from a Server o Registration & Unlicensed Copies ═══ 3.1. Choosing the Target Drive ═══ The "DCF/2 Installation" screen asks you to select the "Target Drive" for the DCF/2 program files. This is the uncompressed drive from which OS/2 will run the DCF/2 programs. ═══ 3.2. Selecting the Number of VDUs ═══ On the "DCF/2 Installation" screen you will enter the "Total VDUs" to be created by the install program. This number can be changed at a later time. Note: In choosing the number of VDUs to create (and realizing that almost no two systems are identical), take the following into consideration. The data on a system usually falls into one of three categories and occupies more or less a fixed percentage of this physical space: Data Categorized by Frequency of Use ┌─────────────────────────┬────────────────────┬─────────────────────────┐ │Category │As % of Physical │Examples │ │ │Space │ │ ├─────────────────────────┼────────────────────┼─────────────────────────┤ │Write seldom/Read seldom │60 % │Icons, .pic files, │ │ │ │communications threads, │ │ │ │tutorials, online │ │ │ │archives, database │ │ │ │backups, etc. │ ├─────────────────────────┼────────────────────┼─────────────────────────┤ │Write seldom/Read often │25% │Applications │ ├─────────────────────────┼────────────────────┼─────────────────────────┤ │Write often/Read often │15% │Live data │ └─────────────────────────┴────────────────────┴─────────────────────────┘ Typically, applications and games compress at 1.5 - 1.75:1, user files compress at 1.75 - 2.25:1 and icons and communications threads compress at 2.25 - 5.0:1. For a number of reasons, we recommend that you create several smaller VDUs rather than a few large ones. We base this recommendation on the length of time required to run CHKDSK /F on a large VDU versus a smaller one; as well as the amount of time required to optimize a large VDU versus a smaller one. Finally multiple smaller VDUs offer greater backup flexibility. ═══ 3.3. Creating VDUs ═══ The first VDU you create will take the first physical drive letter available on your system; the second will take next available drive letter, and so on up to the total number of VDUs you requested be created. For each VDU, you select the drive letter for the "Host Physical Unit for VDU" and the "Total Size in MB." Note: The DCF/2 will allocate its VDU drive letters contiguously from the first available physical drive letter on your computer system at the time the DCF/2 physical device driver loads. This means that, for example, laptop users with docking stations will probably need to use one CONFIG.SYS when docked and a second CONFIG.SYS when running portable. In the latter case, inserting VDISK statements for each of the physical devices not present when portable will allow the VDU drive letter to remain the same in both modes. Choosing Where to Put VDUs This version of the DCF/2 allows you to create as many virtual disk units as you have drive letters available. You can "put" your VDU's on any of your existing disk units, on network drives, floppies, tape, Read-Write Opticals [--] any writeable device supported by OS/2. Selecting the Host Physical Unit The "Host Physical Unit" is the physical location on which the Virtual Disk Unit resides. Note: If the Host Physical Unit contains the SWAPPER.DAT file, we recommend that you preallocate space for the swap file by adjusting the settings in your CONFIG.SYS. Selecting VDU Size The "Total Size" is the total capacity OS/2 will believe the DCF/2 Virtual Disk Unit to have. You enter the size in MegaBytes rather than in bytes. Cancelling Selections Once you have indicated your choices, you can choose to "Create or Update VDU," get "Help," or "Exit/Cancel." The latter allows you to change your mind or correct an unwanted choice. Following the successful creation of your first VDU, the process repeats itself for each subsequent VDU up to the total number of VDUs you requested. ═══ 3.4. Updating the Configuration File ═══ Once your VDUs have been created, the DCF/2 program files are copied to the "Target Drive" and the install program adds the DEVICE, SET and CALL statements to your configuration file. Automatic Update The install program creates the CONFIG.DCF file. This file will replace your existing CONFIG.SYS. First, however, your existing CONFIG.SYS is saved as CONFIG.!D!. The install program includes an edit option to allow you to edit the load order of devices in your CONFIG.SYS before completing the installation process and restarting your system. In most cases, you will not need to do so. Whenever the DCF/2 makes a change to your CONFIG.SYS file, that change will always be delimited by lines and REM statements which explain what was changed and the date and time stamp of the change. The following is an example: Example of Changes to the CONFIG.SYS File "The ordering of the statements in your CONFIG.SYS file has been adjusted to put the HPFS.IFS statement at the top, followed by the DISKCACHE statement if you have FAT drives. This is followed by your original CONFIG.SYS statements, (with the earlier HPFS and DISKCACHE statements REM'd out with a time stamp), followed by the DCF/2 virtual disk definitions, followed by DCF/2 CALL=x:\DCF2\DCF2.EXE /A:STARTUP statement. Your HPFS and (optionally) your DISKCACHE statement may have been modified to optimize your cache allocation and/or to add AUTOCHECK switches. The DCF/2 requires that the HPFS.IFS have a minimum cache of 1024. In the following example, the /CACHE parameter determines the number of KiloBytes of memory allocated to HPFS cache blocks. The /AUTOCHECK tells the HPFS to CHKDSK any 'dirty' HPFS disks: IFS=C:\OS2\HPFS.IFS /CRECL:64 /CACHE:1536 /AUTOCHECK:FEG The DISKCACHE statement is required only if you have FAT drives on your system. If you have no FAT formatted drives, this statement is REM'd out thereby freeing up the memory it would have otherwise committed. In the following DISKCACHE statement, the first number is the number of KiloBytes allocated to FAT caching. The LW parameter enables FAT lazy-writing, the number following that is the threshold, and the AC: specifies which FAT drives to CHKDSK during system startup. For additional information on the DISKCACHE statement, refer to the OS/2 Online Help. DISKCACHE=1024,LW,32,AC:C The following commands can improve your caching performance, depending on how you use your system: o REM >> RUN=x:\OS2\CACHE.EXE /MAXAGE:40000 o REM >> RUN=x:\OS2\CACHE.EXE /DISKIDLE:30000 o REM >> RUN=x:\OS2\CACHE.EXE /BUFFERIDLE:20000 Due to the multithreaded nature of the OS/2 system startup, you may find that you need to place the above RUN commands in your STARTUP.CMD folder instead of in your CONFIG.SYS. The contents of your CONFIG.SYS file follow these statements and these are followed by the DCF/2 device, set and call statements at the end of your CONFIG.SYS. The DCF/2 statements will be commented and surrounded with delimiting lines. The DCF/2 device drivers are order dependent and each must appear on a separate line. The DCF2PDD.SYS comes first. The /U:n defines n number of DCF/2 virtual disk units to be created. DEVICE=C:\DCF2\DCF2PDD.SYS /u:3 DEVICE=C:\DCF2\DCF2CDE.SYS The DCF _VDU_x environment variable points to DCF/2 VDU x: SET DCF2_VDU_E=C:\DCF2\DCF2_E.VDU SET DCF2_VDU_F=C:\DCF2\DCF2_F.VDU SET DCF2_VDU_G=C:\DCF2\DCF2_G.VDU The following DCF/2 DIAGNOSTIC statements are to aid in diagnosing virtual drive characteristics and problems: REM >> SET DCF2_ACP_LOGNG=3 REM >> SET DCF2_VCP_LOGNG=3 REM >> SET DCF2_ACP_DEBUG=3 REM >> SET DCF2_VCP_DEBUG=3 The following "CALL=" statement starts the DCF/2. If you have put DCF/2 virtual disk units on network disks or other media which is not available at boot time, move this statement to your STARTUP.CMD or to the command procedure that starts your network. The following call statement tells OS/2 to startup the DCF/2: CALL=C:\DCF2\DCF2.EXE /A:STARTUP You may delete the REM'd statements and delimiting lines if you prefer. Do, however, exercise caution so as not to delete more than the comments." DCF/2 OS/2 System Shutdown Icon During the final part of the installation process, the program will place the DCF/2 icon on your desktop and display the DCF/2 README file. It will then ask if you would like to restart your system at this time. README.11b The README.11b file shipped on the DCF/2 disk contains the latest release notes for this version of the software. You can elect to have both the README.1st and README.11b copied to the DCF/2 program directory when you run the DCF/2 install program. Regardless, you will have an opportunity to view the file automatically just prior to exiting the DCF/2 install program and restarting your system. ═══ 3.5. Restarting Your System ═══ The DCF/2 device statements added to your CONFIG.SYS will not take effect until such time as your system is restarted. Before exiting the DCF/2 install program, the program will ask you if you would like to have your system restarted automatically at this time. If you answer, "yes," the install program will run shutdown. You can choose to exit the program and do the reboot later. Once you have successfully created your VDUs and your system has been rebooted, each of your VDUs will automatically be formatted using the HPFS format. On a standard OS/2 system, this will happen prior to the time OS/2 loads the Workplace Shell. ═══ 3.6. Formatting VDUs with AutoFormat ═══ The VDUs you created during the install are unformatted until your system restarts; then the DCF/2 uses the OS/2 format command to format each of them as HPFS drives. The format uses an "undocumented OS/2 2.1 feature" [--] the NOF switch [--] for fast format. The formatting process can take from a few seconds using the switch to a couple of minutes without it, depending upon the size of the drive being formatted and the speed of your computer. The format command will prompt you to enter a volume label or press enter. At this point, the volume information is written to the VDU's boot record. ═══ 3.7. AutoChecking VDUs ═══ The DCF/2 uses OS/2's CHKDSK /F to check the newly formatted drive. Be sure to "press any key to continue" when prompted to do so! This process repeats for each of the VDUs you created during the installation program. ═══ 3.8. Formatted, Clean and Ready for Data ═══ The DCF/2 startup continues, the DCF/2 Space Manager is launched for each VDU and the Workplace Shell comes up. At this point, your VDUs are formatted, empty and available. You may now begin to move data and user files onto them [--] using the tools you normally use to move directories and files on your system. ═══ 3.9. DCF/2 OS/2 System Shutdown Program ═══ During the DCF/2 installation, a DCF/2 Shutdown icon was placed on your OS/2 Desktop. By using the DCF/2 System Shutdown instead of the normal OS/2 Shutdown, you do two things: First, you insure that all of your VDUs are shutdown properly and that the shutdown process continues through the final Control-Alt-Delete box. Second, by using the DCF/2 System Shutdown, you by pass the DCF/2 AutoCheck feature at system startup. Depending upon the number of VDUs you have and their size, the auto CHKDSK /F process can be a time consuming one. It's time you can save by using the DCF/2 System Shutdown program. Optional Parameters for Shutdown The following optional parameters are available for the SHUTDOWN.EXE program shipped with the DCF/2 and can be added to the optional parameters line in the DCF/2 System Shutdown program's settings notebook on your desktop: Parameter Function /i Interactive shutdown. Prompts you to answer yes/no to cancel shutdown. /n No system shutdown. Shuts down the DCF2ACP only. /t "Thinkpad" or the like. This optional parameter doesn't kill processes, but shuts down the DCF2ACP.EXE and system. /s Single click shutdown. On some systems, this may result in an infinite shutdown loop! /d: Default time in seconds for the Shutdown Countdown. The default is 10 seconds. Increase this number if your do not reach the final C-A-D box at shutdown. /w: Smallest Process ID number (detached processes) in a range of PIDs to "kill" at shutdown. /W: Largest Process ID number (detached processed) in a range of PIDs to "kill" at shutdown. For additional information on the DCF/2 OS/2 System Shutdown program, please refer to the section on the program in the User Reference. ═══ 3.10. Installing from a Network Server ═══ You can install the DCF/2 to a central location on a server. First, make a directory on the server, e.g., DCF2DIST; then copy the DCF/2 program files to that directory. COPY A:*.* P:\DCF2DIST\*.* In the above example, the DCF/2 disk is in your A: drive and you are copying the files to a directory called DCF2DIST on server drive P: On each workstation, create a temporary directory; then logon to the appropriate network drive and change to the DCF2DIST directory. Copy the files from the DCF/2 program directory on the server to the temporary directory on the workstation. (In, the following example, the temporary drive "TMP" is on drive "x".) COPY P:\DCF2DIST\*.* x:\TMP Important: Before installing the DCF/2, the workstation must logoff of the network. If this is not done, the first VDU will take an incorrect drive letter. The client workstation then installs the DCF/2 from the temporary directory, by changing to the temporary directory and running the DCF/2 install program. X:\TMP\INSTALL ═══ 3.11. Updating Workstations from a Network Server ═══ When the install program is used to update an existing DCF/2 program area on a client workstation, only the DCF/2 program files are changed. This process can be done directly from the central server and does not require that the client workstation logoff the network at any time during the procedure. ═══ 3.12. Registration & Unlicensed Copies ═══ Your DCF/2 package includes a registration card. Please take the time to fill out your registration card and return it to us so that we can notify you when updates to the DCF/2 are available. If you are interested in testing future releases of the DCF/2, please check the "Beta" test program box. All registered users who would like to beta test are eligible to do so. Access to CompuServe or IBMLink is a required. If this copy of the DCF/2 is an unregistered copy -- one not purchased -- it will "sing". The sound is our "nagware." While we wish to give those who feel they need an opportunity to "try before you buy," the opportunity to do so, the DCF/2 is neither "shareware" nor "freeware" but licensed software. To license it one must purchase it. See the second page of the REMINDER.LOG generated in your in the root directory of your boot drive for information on purchasing the DCF/2. If your licensed copy of the DCF/2 continues to sing, we apologise. Please contact technical support at your earliest convenience. Telephone technical support is available to registered users only and is reached by calling (303) 484-2400 between the hours of 8 a.m and 4 p.m U.S. Mountain Time Online technical support is available to both registered and unregistered users through the Proportional Software OS2BBS CForum (OS2DCF2 via IBM TalkLink and Advantis) and through the Proportional Software Vendor Forum on CompuServe (GO OS2AVEN). ═══ 4. The DCF/2 Big Picture ═══ The DCF/2 is an on-the-fly data compression facility for all OS/2 file systems. Transparent to all standard DOS, Windows, and OS/2 applications software, the DCF/2 works with all existing disk structures - NO repartitioning of your existing system is needed. The DCF/2 is a full 32-bit program for OS/2 2.X. The DCF/2 supports all OS/2 file systems as host storage for compressed, HPFS-formatted virtual disk units (VDUs), so long as you are running OS/2 2.11 or greater. For users running OS/2 2.0, OS/2 2.1 or or OS/2 for Windows, only FAT-based host storage is supported. For the OS/2 2.11 user, the host drive can be an existing FAT or HPFS partition, a network drive -- even removable media like floppies or read/write or magneto optical drives. The DCF/2 is a system of building blocks designed to grow with your entire operating environment - IBM's OS/2 2.1 32-bit multitasking makes it all possible! The following topics are covered in this section: o Product Architecture o How It Works o What is a "VDU"? o Compression ═══ 4.1. Product Architecture ═══ The following diagram of the DCF/2's architecture details these building blocks: The DCF/2 Architecture The DCF/2 is designed with each element externalized. Third-party developers can add compression, encryption, and other disk related capabilities to your system environment (contact the PSC technology lab for pricing and details of the DCF/2 CDE API kit). ═══ 4.2. How It Works ═══ When the OS/2 operating system or an application program requests disk accesses, the DCF/2 Physical Device Driver (PDD) receives the request and repackages it for processing by the Ancillary Control Process (ACP). The ACP is a standard, high-level software layer which shuffles the compressed disk request between Compression/Decompression Engines (CDE's), Input/Output Engines (IOE's), and physical disk structures. The ACP compressed disk requests are processed and managed by standard OS/2 disk and file services. The DCF/2 can use all logical media, such as hard disk drives, LAN network drives, and removable media like floppies. This architecture guarantees compatibility with all OS/2 system and application software updates. The DCF/2 VDU Control Process initializes all VDUs during OS/2 system startup and then launches the DCF/2 space manager. The latter monitors the amounts of virtual and physical space in use to prevent the user from running out of physical space on the host volume. The DCF/2 benefits from all OS/2 file and memory management features, so that applications 'see' the DCF/2 VDU as a "real" disk. The DCF/2 takes advantage of the OS/2 High Performance File System, allowing DCF/2 VDU's to utilize all of its advanced features like 255 character file names, integrated extended attributes, and support for HUGE disks. ═══ 4.3. What is a "VDU"? ═══ "VDU" is short for "Virtual Disk Unit." If you think in terms of the types of drives you work with, they are usually either "physical" or "logical." A physical drive is one you can reach out and touch. You use low level utilities, like FORMAT and CHKDSK, on a physical drive. A network drive is an example of a logical disk unit. You cannot touch it. And you cannot run low level utilities, like FORMAT and CHKDSK, on it. A "Virtual Disk Unit" is a cross between the two. Like a network drive, it is logical rather than physical. Like a physical drive, you use low level utilities, like FORMAT and CHKDSK, on it. In reality, a VDU is a flat, simple file with no EAs (extended attributes), in which your data is stored in compressed format. Because it is just a flat file, it can reside on any device supported by OS/2 [--] be that FAT, HPFS, network or removable media. ═══ 4.4. Compression ═══ There are two basic kinds of data compression: (1) Lossless and (2) Lossy. Lossless data compression requires that whatever goes into the compression engine comes out in the same form. Lossy compression allows for statistical recovery of information, allowing data dilution. The DCF/2 supports only lossless data compression technologies. Uncompressed sectors are passed through the DCF/2's character based compression engine. The resulting logical disk sectors (LDS) require less physical space than their uncompressed counterparts. Each virtual disk unit has an intelligent disk allocation table (DAT) which describes where compressed logical disk sectors reside within the container file. In addition, the DAT keeps track of the compression type performed on each compressed chunk and how many times the chunk has been accessed, compressed, and/or decompressed. Your VDU develops a personality of its own as it matures, based upon the way you use it. What to Compress The DCF/2 includes a utility called the "Disk Compression Analysis Tool" or "DCAT." It allows you to look at the data on your system in terms of the amount of space storing the data on a virtual disk unit will return to you. You can use the DCAT to look at your whole physical disk unit or at directories and subdirectories on your logical drives. You can sample data in a variety of ways depending upon your needs. In general, you will find that user files compress best. For example, Lotus AmiPro user files compress at about 5:1. Windows and DOS program files compress next best [--] usually at 2:1 and better. OS/2 MDOS and WINOS2 program compress at about 1.81:1. Game files compress poorly at 1.5:1. What Not to Compress Some files should not be compressed at all. For example, all files needed to boot your system must be left uncompressed, because they are required before your compressed virtual disk units are available. For more information on compressing OS/2, refer to the following section on (Compressing OS/2 Itself.) Some files won't compress or will compress very little. These include files you have archived with utilities like ZIP(tm), PKZIP(tm), ARC(tm), and LHARC(tm), and files that are shipped already compressed [--] for example, game and sound files. You should leave uncompressed files you want access to if you use Dual Boot or Boot Manager to boot an operating system other than OS/2. Data stored on your DCF/2 virtual disk units is not accessible when you boot native DOS. Compressing OS/2 Itself The operating system (OS/2) is like a puzzle which rebuilds itself each time you "reboot" your system. It does so in phases. The first is system initialization. The second is system startup. During system initialization, base device drivers, device drivers, and basic system-wide information are loaded. The DCF/2 physical device driver (DCF2PDD.SYS) loads at this time. During system startup the operating system loads high-level file services, user interface and management programs (Presentation Manager), and initializes user-specific actions (STARTUP.CMD and STARTUP FOLDER). The DCF/2 ancillary control process (DCF2ACP.EXE) and its associated support processes load at this time. Those parts of OS/2 required prior to the time when OS/2 loads the DCF/2 device drivers and executes the CALL statement to startup the DCF/2 cannot be stored on a compressed drive. Our recommendation is that you allocate to OS/2 the space it requires and compress your applications software, utilities, user files and things like icons, clipart and communications threads, etc. That said, you can move some parts of OS/2 to a VDU and run them quite successfully. For example, you can move WINOS2 to a VDU to free up about 8MV of space on your OS/2 boot drive. When you do so, you must modify the OS/2 PATH and DPath statements to properly reference the new WINOS2 subdirectory. Also modify the AUTOEXEC.BAT file to point to the new WIN\OS2 directory. If you installed them, you can also gain additional space on your OS/2 boot drive by moving EPD (the Enhanced Editor) and OS/2 reference files (.INF) to a VDU. ═══ 5. DCF/2 and Your System Startup ═══ At OS/2 system startup (on a standard system running the Presentation Manager), the DCF/2 startup process will complete before the Presentation Manager comes up. The DCF/2 startup process involves scanning all of the VDUs, formatting and/or running CHKDSK on any VDUs that are either unformatted or were left "dirty" by an improper shutdown, and launching the space manager. If your system is improperly shutdown, e.g., you turn it off without running the DCF/2 System Shutdown program, you have a power failure, or your system experiences a trap or the system hangs necessitating a reboot, the DCF/2 will automatically run CHKDSK /F on each VDU during the OS/2 boot process. This checks your VDUs for errors and makes the necessary repairs. It keeps you from causing further damage to a damaged VDU. You can use CONTROL-C to terminate the AUTOCHECK process. However, as a safeguard, the VDU remains "dirty" until you run CHKDSK /F on it -- even if you run a proper shutdown using the DCF/2 System Shutdown. If you find you want to interrupt the startup process, you can. When prompted, depress the CONTROL key to interrupt the startup process and exit to an OS/2 command processor. To resume the startup process, type "EXIT". Far less often, you may find you need to keep the DCF/2 from loading at all. To abort the DCF/2 load, depress one or both SHIFT key(s) when prompted to do so. OS/2 will not load the DCF/2 device drivers. Note: Your VDUs will not be available until you restart your system. The remainder of this section covers startup on your system of the: o The DCF/2 Device Drivers o The DCF/2 Control Program o The DCF/2 VDU Control Process o The DCF/2 Ancillary Control Process ═══ 5.1. The DCF/2 Device Drivers ═══ The DCF/2 is not designed as an IFS (installable file system). The DCF/2 install program placed two two device drivers in your CONFIG.SYS file. OS/2 loads these at system startup. The DCF2PDD The DCF/2 Physical Device driver defines a block device in your CONFIG.SYS that "creates" your compressed drive. It must load in your CONFIG.SYS prior the DCF2CDE.SYS. The DCF2CDE The DCF/2 Compression Decompression Engine (DCF2CDE.SYS) is a character-based device driver. As requested data is passed to it, it compresses or decompresses that data and passes it on. ═══ 5.2. The DCF/2 Control Program ═══ The DCF/2 Control Program (DCF2.EXE) is the command line interface for the DCF/2 on non-PM systems. It will also be used on a PM system if you want to create or remove VDUs once you have installed the DCF/2 and created your initial VDUs. The CALL statement the DCF/2 install program inserted at the end of your CONFIG.SYS, calls the DCF/2 control program, which in turn lauches the DCF2ACP and DCF2VCP programs. Refer to the appendix for a list of DCF2.EXE commands and parameters. ═══ 5.3. The DCF/2 VDU Control Process ═══ The DCF/2 VDU Control Process (DCF2VCP) performs two functions. First, it creates the control processes run during your system's startup. It initializes the disks. Then, during run-time, it controls space management for each VDU using the DCF2INFO.CMD file. Space Management File Each VDU has a DCF/2 Space Manager File, DCF2INFO.CMD. This file reports the VDU's current compression ratio and available compression ratio after recompaction. This file also reports the total size of, amount of space in use by and space available for both the VDU's physical host drive and for the VDU itself. The purpose of this file is to protect you from running out of physical space on the VDU's host drive [--] a condition which can jeopardize the integrity of the VDU. The file may appear to be very large at times. In reality, it occupies very little space and is stored in the VDU's Disk Allocation Table in single-byte entries. To display the file, go to an OS/2 command prompt and type the VDU drive letter followed by a colon and DCF2INFO, e.g., X:DCF2INFO. If you are not in the root, use \X:DCF2INFO, where X is the drive letter for the VDU. To exit, type Control-C. ═══ 5.4. The DCF/2 Ancillary Control Process ═══ The DCF/2 Ancillary Control Process (DCF2ACP) is the software controller for the virtual disk drive. It connects drive letter X to the VDU container file. For example, you might have a VDU drive letter E: and a VDU container file C:\DCF2\DCF2_E.VDU. The DCF2ACP "connects" the two. While you will need to do so only seldom [--] for example, to delete a VDU container file or to update the DCF/2 program files [--] you can easily stop and start the DCF2ACP using the DCF/2 Control Program. To try it, change to your DCF2 program directory, type DCF2 /A:SHUTDOWN to stop the DCF2ACP and DCF2 /A:STARTUP to restart it. Note: If the DCF2ACP is stopped, your VDUs and the programs and data on them are not available. This makes sense if you think in terms of your physical disk controller [--] were you pull your physical disk controller out of your computer, the programs and files on your physical disk would not be available. ═══ 6. OS/2 File Systems ═══ A file system determines how data is stored on your disk. OS/2 supports two basic file systems: FAT and HPFS. The key difference between the two file systems is the way in which they manage the date stored on your disk. The following topics are covered in this section: o The FAT File System o The HPFS File System o HPFS vs. FAT Summary o Floppies o DCF/2 and the OS/2 File Systems o Physical Drive Management o Virtual Drive Management o Backing Up ═══ 6.1. The FAT File System ═══ The FAT file system stores data using clusters. The size of the cluster used depends upon the size of the drive. Typically, the cluster size is 4 Kbytes; but as the size of the drive increases, the size of the cluster increases to 8 or even 16Kbytes. This increase is due to the limitation on the maximum number of entries that can be supported by the File Allocation Table (64K entries). The FAT supports only the "eight-dot-three" convention for file names. That is, file names can use up to eight alphanumeric characters followed by a period and a three alphanumeric characters. ═══ 6.2. The HPFS File System ═══ The High Performance File System or HPFS stores data at sector granularity [--] 512 bytes per sector. The HPFS includes sophisticated caching and lazy writing mechanisms. Finally, the HPFS employs an extremely efficient mechanism for searching. It supports file names up to 254 characters in length, providing the user with the ability to use far more descriptive file names than the eight character plus three character extension available using FAT. ═══ 6.3. HPFS vs. FAT Summary ═══ Statistically over a FAT formatted drive, one half of the cluster size is lost in slack space. Actually, it can be worse than that [--] especially if you have a lot of small files, like icons. An icon is typically slightly less than 1Kbytes big, but a FAT-formatted partition, with a minimum cluster size of 4Kbytes will require 4Kbytes to store this 1Kbyte file. If you store 4,000 1K big icon files on a FAT partition, you will use 16MB [--] 12MB of the 16MB are lost in slack space! On an HPFS-formatted drive, to store the same 1K icon file requires only 1024 bytes. To store the same 4,000 1Kbyte big icon files that required 16MB on a FAT-formatted partition, requires only 4 MB! The HPFS also offers several other benefits. Among these are a highly efficient binary-tree search mechanism, ability to use up to 254 characters for file names, and optional cache tuning parameters which can improve system performance by 25 to 30%. ═══ 6.4. Floppies ═══ A floppy drive is DASD device. It is always formatted to use the File Allocation Table. Using the DCF/2, you can put HPFS-formatted VDU's on FAT-based floppy devices. ═══ 6.5. DCF/2 and the OS/2 File Systems ═══ DCF/2 VDUs are formatted using the OS/2 High Performance File System (HPFS). Based upon extensive comparisons of the two file systems, we have concluded that an HPFS-formatted drive is faster and more efficient than the equivalent size FAT (File Allocation Table) formatted drive -- independent of the size of the drive. ═══ 6.6. Physical Drive Management ═══ It is important to take 'good care' of your physical disk storage before doing anything with DCF/2 virtual disk units. This is because the virtual disk units reside on physical storage and if it is not correct, that can cause unnecessary risk to the virtual disk container file. In most cases, the only thing you have to do to maintain your physical disk integrity, it to make sure you 'AUTOCHECK' your physical disk drives at startup time. The DCF/2 installation procedure automatically insures this by correcting the IFS= and DISKCACHE= CONFIG.SYS statements, if the AUTOCHECK option is not already there. If you do experience a physical disk integrity problem make sure you properly shutdown (using the DCF/2 provided shutdown icon or SHUTDOWN.EXE program) and then make sure that the CHKDSK operation is performed during system restart. ═══ 6.7. Virtual Drive Management ═══ DCF/2 virtual disk units should be treated exactly as you do physical disk units, except (as noted above) that the physical disk management MUST be performed BEFORE any DCF/2 virtual disk maintenance. ═══ 6.8. Backing Up ═══ The DCF/2 virtual disk units offer you a great deal of backup flexibility. You can backup the VDU container file itself and have an 'image' backup of the compressed volume. You can backup the individual files in the VDU and have file-by-file backup of your compressed storage. This method provides an uncompressed copy of each file in the VDU's compressed storage. In either case, the important part is that you do backup you data (both physical and virtual). Disk drives are mechanical things -- eventually they are going to fail. So don't put this important system's management function off until it's too late! ═══ 7. DCF/2 User Reference ═══ The User Reference is divided into the following sections, which describe the functions and operations of the DCF/2 program modules. o System Startup o DCF/2 Control Program (DCF2.EXE) o DCF/2 Ancillary Control Process (DCF2ACP.EXE) o DCF/2 VDU Control Process (DCF2VCP.EXE) o DCF/2 Monitor (DCF2MON.EXE) o DCF/2 Shutdown Program o DCF/2 OPTIMIZE (Recompaction) Utility o DCAT (Disk Compression Analysis Tool) o Moving Files from Physical to Virtual Space ═══ 7.1. System Startup ═══ During system startup, the DCF/2 is linked to the OS/2 operating system to provide transparent access to your virtual, compressed disk storage. The HPFS.IFS The DCF/2 relies on the OS/2 High Performance File System (HPFS) for all virtual disk operations. Normally the IFS= CONFIG.SYS statement will be at the beginning of your system startup. The DCF/2 Device Statements The DCF/2 virtual disk "block devices" are created when OS/2 loads the DCF2PDD.SYS device driver. The "/U:" option determines how many template virtual disk units are created. These are associated with virtual disk unit container files using environment strings (see below). The DCF/2 Environment Strings The DCF/2 associates a virtual drive unit with it's container file using a process environment string of the form: DCF2_VDU_x=full_file_path, where "x" is the VDU drive letter to be associated with "full_file_path" file name. A full file path is normally "d:\dir\filename.ext." The CALL=DCF2.EXE The DCF/2 is actually started, normally, at the very end of the system CONFIG.SYS using the CALL= startup statement. During DCF/2 startup, the system startup can be interrupted or aborted as described during system startup. Using Startup.CMD instead of CALL=DCF2.EXE If you have placed DCF/2 VDUs on network drives which are not available during system startup, move the "CALL=DCF2 /A:STARTUP" statement from the CONFIG.SYS to your STARTUP.CMD file. Place it in the STARTUP.CMD after the statements that start your network software. ═══ 7.2. The DCF/2 Control Program (DCF2.EXE) ═══ You can add or remove drive letters and create VDU's using the DCF/2 control program. Refer to the Appendices for a list of the program's commands and switches. Add a VDU In the example outlined below, we will add a third VDU, (G:) with a size of 100 MB. The process has two steps. First, we will will make two edit changes to the DCF/2 statements in the CONFIG.SYS. Second, we will use the DCF/2 Control Program to create the VDU. Add a VDU Drive Letter First, we need to edit /:u pararmeter following the DCF/2 physical device driver statement in the CONFIG.SYS file. The /:u dictates the total number of VDU drive letters. To add one VDU drive letter, we will increase this number by 1. Say, for example, our system has a physical drive C: with a logical partition D: and we created two VDUs when we installed the DCF/2. These are drives E: and F:. Currently, the /:u parameter is the number 2. When we add the next VDU drive letter, we increase this number goes up by 1 to the number 3. Now our system has VDU drive letters E:, F:, and G:. At this point, we have a new drive letter, G:, but nothing points to it until we add an environment string to associate G: with the VDU container file. (Have patience, we will create the VDU container file next, using the DCF/2 Control Program after the next step.) Let's continue using the system from the example from above. The environment strings in the CONFIG.SYS look like the following: SET DCF2_VDU_E=C:\DCF2\DCF2_E.VDU SET DCF2_VDU_F=D:\DCF2\DCF2_F.VDU Say we want our new VDU G: to reside on D:. The environment statement will look like this: SET DCF2_VDU_G=D:\DCF2\DCF2_G.VDU Create the VDU Container File Having made the necessary changes to the CONFIG.SYS, we are ready to use the DCF/2 Control Program to create the VDU. When we added the environment string to the CONFIG.SYS file, we gave the container file the following path and file specification: D:\DCF2\DCF2_G.VDU. To create the VDU, change to the DCF2 program directory. Use the following command to create our 100MB VDU G: DCF2 /V:CREATE /S:100 /F:D:\DCF2\DCF2_G.VDU The parameters used above are /V: (Virtual Disk Unit), /S: (Size in MB) and /F: (Path and File Specification). Restart the Computer The final step in the process is to restart the computer system. This initializes the changes made to the CONFIG.SYS and runs FORMAT on the new VDU. Deleting a VDU In the event you want to remove a VDU, the procedure involves three steps. Note: Deleting a VDU deletes all of the data stored in the VDU. Be sure to make a backup copy of any of the data you do not want to delete permanently before proceeding. Remove the VDU Drive Letter To remove the VDU drive letter, you edit the DCF/2 statements in your CONFIG.SYS. First, look for the /u: parameter following the DCF2PDD.SYS and reduce the number by 1. Next remove from the CONFIG.SYS the SET statement which points to your last drive letter, e.g., SET DCF2_VDU_G=D:\DCF2\DCF2_G.VDU Save the change and exit from the CONFIG.SYS. Delete the VDU Container File To delete the VDU, change to the DCF2 program directory. Use the DCF2 /- to stop the DCF2ACP. DCF2 /A:SHUTDOWN To protect you from inadvertantly deleting your VDU(s), we set the system attribute. For DELETE to access a VDU, you must remove this attribute: ATTRIB *.VDU -S Use the DELETE command to delete the VDU container file. In the case of the system described in the section on adding a VDU, the last VDU is G:. The following command would delete the file: DELETE DCF2_G.VDU /V Restart the Computer As always, changes to the CONFIG.SYS are only initialized after the computer is restarted. ═══ 7.3. DCF/2 Ancillary Control Process (DCF2ACP.EXE) ═══ Just as a physical disk unit has a controller, so do our virtual disks. The "ACP" is the virtual disk's controller. When the DCF2ACP is stopped, it is analogous to pulling your physical disk's controller out of your system box. You cannot access compressed data on a VDU if the DCF2ACP is not running. Any DCF/2 Ancillary Control Process error conditions are reported in the DCF2ACP.LOG file created in the root of your OS/2 boot drive. If you experience a problem, you may want to enable DCF2ACP logging to a greater degree. You can do so by removing the REM >> from the DCF2ACP logging statement in your CONFIG.SYS and reboot. Or you can issue the following SET command: SET DCF2_ACP_LOGNG=3 SET DCF2_ACP_DEBUG=3 The DCF/2 takes advantage of the sophisticated caching mechanisms available with the High Performance File System. Anytime you write data to cache blocks -- whether using the DCF/2 of not -- there is the risk that it will be lost should the power to the machine be interrupted. We feel the performance benefit caching provides far out weighs this risk. But, just in case you do not share these sentiments, enter the following SET statement in your CONFIG.SYS: SET DCF2_ACP_MISSION_CRITICAL=1 ═══ 7.4. DCF/2 VDU Control Process (DCF2VCP.EXE) ═══ The DCF2VCP manages the virtual disk units you create using the controller (DCF2ACP). During system startup, the DCF2VCP initializes your VDUs and launches the DCF2ACP and Space Manager. Any DCF/2 VDU Control Process error conditions are reported in the DCF2VCP.LOG file created in the root of your OS/2 boot drive. If you experience a problem during system startup, you may want to enable DCF2VCP logging to a greater degree. You can do so by removing the REM >> from the DCF2VCP logging statement in your CONFIG.SYS and reboot. Or you can issue the following SET command: SET DCF2_VCP_LOGNG=3 SET DCF2_VCP_DEBUG=3 ═══ 7.5. DCF/2 Monitors (DCF2MON.EXE) ═══ The monitors are LED icons -- one for each VDU you create. They flash to indicate drive activity. Monitor LEDs flash red for write and blue for read operations. They flash green during compression and yellow during decompression. If you need to create a VDU LED manually, do the following: 1. Use the drives icon to open the DCF2 program directory. 2. Locate the DCF2MON.EXE icon in the DCF2 program directory. 3. Drag the icon to your Startup folder. (Control+Right Mouse Button) 4. Open the settings notebook for the icon. 5. Go to the parameters box on the program setting page. 6. Enter /l:X, where X is the VDU drive letter. 7. Close the settings notebook. 8. Double click on the VDU LED to put it on your desktop. You can move the icon to a specific location on your desktop and save that location so that when you restart your system, the icon comes up in that location. To do so, drag the icon to the desired location. Double click on the icon to close it. Reboot your system. The icon's location coordinates are now saved. You can make your VDU LEDs larger. Click the minimize button on the LED. The icon disappears from the desktop and reappears in your minimized window viewer -- bigger. Hint If you double click on an LED icon in your Startup Folder and the Window List pops up, look for the LED icon in your Minimized Window Viewer. The following are optional parameters for DCF2MON.EXE. and are specified in the parameters box in the LED icon's settings notebook on the program settings page. Parameter Function /l:X VDU Drive letter for this LED icon. /x: followed by a decimal value. Designates the x coordinate location of the LED icon on your Desktop. /y: followed by a decimal value. Designates the y coordinate location of the LED icon on your Desktop. /t: followed by time in seconds. Establishes the refresh frequency for the LED icon. Increase this if you feel the monitor refreshes are loading your system. (Applies to certain video adaptors.) ═══ 7.6. DCF/2 Shutdown Program ═══ During the DCF/2 installation, a DCF/2 Shutdown icon was placed on your OS/2 Desktop. By using the DCF/2 System Shutdown instead of the normal OS/2 Shutdown, you do two things: First, you insure that all of your VDUs are shutdown properly and that the shutdown process continues through the final Control-Alt-Delete box. Second, by using the DCF/2 System Shutdown, you by pass the DCF/2 auto-check feature at system startup. Depending upon the number of VDUs you have and their size, the auto CHKDSK /F process can be a time consuming one. It's time you could have saved by using the DCF/2 System Shutdown program. The DCF/2 OS/2 System Shutdown broadcasts a message to all PM applications -- regardless of whether they are running from virtual or physical storage. If this causes you problems when your system restarts, you may need to add those running on your VDUs to your STARTUP Folder. Optional Parameters for Shutdown The following optional parameters are available for the SHUTDOWN.EXE program shipped with the DCF/2. Most of these, you will never have call to use. They can be added to the parameters box on the program settings page of the DCF/2 System Shutdown icon's Settings Notebook on your Desktop: Parameter Function /i Interactive shutdown. Prompts you to answer yes/no to cancel shutdown. /n No system shutdown. Shuts down the DCF2ACP only. /t "Thinkpad" or the like. This optional parameter doesn't kill processes, but shuts down the DCF2ACP.EXE and system. /s Single click shutdown. On some systems, this may result in an infinite shutdown loop! /d: Default time in seconds for the Shutdown Countdown. The default is 10 seconds. Increase this number if your do not reach the final C-A-D box at shutdown. /w: Smallest Process ID number (detached processes) in a range of PIDs to "kill" at shutdown. /W: Largest Process ID number (detached processed) in a range of PIDs to "kill" at shutdown. Important If you use Dual Boot, add the /n parameter to the SHUTDOWN.EXE under Parameters in the settings notebook for the DCF/2 System Shutdown icon. Use the icon to shutdown the DCF/2 first and then use your Dual Boot icon. The DCF/2 installation program put an OS/2 System Shutdown icon on your desktop. If you are truly addicted to running shutdown using the right mouse button, we suggest that you add the DCF/2's OS/2 System Shutdown as an item on your desktop menu. To do so: 1. Click the right mouse button to pop-up the Desktop menu. 2. Click on OPEN. 3. Click on SETTINGS. 4. Click on MENU. You will see a box labelled: "Actions on Menu: Primary Pop-up Menu." 5. Locate the DCF/2 OS/2 System Shutdown icon on your Desktop and drag it the box described in the proceeding step. 6. Close the settings notebook. ═══ 7.7. The DCF/2 OPTIMIZE (Recompaction) Utility ═══ Note: Your VDU(s) and the programs and data on them are not available to you during this process. The length of time required to recompact a VDU will vary with speed of your computer processor and the size of the VDU. Refer to the tables below to determine how much time to allow to recompact the VDU(s) on your computer system. The Optimizer (DCF2PAKR) is the program you will run when you want to purge your VDU(s) of deleted space and compress to maximum the data stored in it. While it can be, it is not necessary to run this program on a daily basis [--]once a week should be sufficient. To optimize a 200 MB Virtual Disk Unit with 190 MB in use on a 586/60 class machine will require 20-25 minutes. Since not all VDUs are created and optimized on a Pentium, the following table describes the estimated time required to optimize selected-size VDUs on a 486/66 class machine: Estimated Time Required to Optimize Your VDU ┌────────────┬──────────────────────────────────────┐ │VDU Size │Estimated Time to Complete │ ├────────────┼──────────────────────────────────────┤ │100 MB │15 minutes │ ├────────────┼──────────────────────────────────────┤ │200 MB │30 minutes │ ├────────────┼──────────────────────────────────────┤ │500 MB │75 minutes │ ├────────────┼──────────────────────────────────────┤ │1 GB │2 1/2 to 3 hours │ └────────────┴──────────────────────────────────────┘ In order to estimate the length of time recompacting the VDU(s) will require on your system, refer to the following table. 1K Chunks Optimized per Minute by Machine Class ┌──────────────────────┬──────────────────────────────────────┐ │Class of Machine │Minutes per 1K Chunks │ ├──────────────────────┼──────────────────────────────────────┤ │486/50 - 586/60 │1 minute per 1K chunks │ ├──────────────────────┼──────────────────────────────────────┤ │486/25 - 486/50 │3 minutes per 1K chunks │ ├──────────────────────┼──────────────────────────────────────┤ │386/33 │5 minutes per 1K chunks │ ├──────────────────────┼──────────────────────────────────────┤ │386/10 - 386/25 │Up to 10 minutes per 1K chunks │ └──────────────────────┴──────────────────────────────────────┘ Optimizing a VDU involves four steps: Purging the VDU(s), stopping the DCF2ACP, optimizing the VDU(s) and then restarting the DCF2ACP. Purging VDUs Purging removes deleted space from VDU(s). You purge a VDU prior to optimizing it. To purge VDU E: you use the following command in which the /P parameter means PURGE and /V: is following by the drive letter of the target VDU: DCF2PAKR /P /V:E Stopping the DCF/2 in Preparation to Optimize VDUs Before you can proceed to OPTIMIZE your VDUs, you must first stop the DCF2ACP. To do so, use the following command: DCF2 /A:SHUTDOWN Remember that your VDUs and the data on them will not be available until you restart the DCF2ACP. Recompressing VDUs You OPTIMIZE your VDU(s) only after you have purged them of deleted space. This process will recompress each chunk of compressed data stored in the VDU at its maximum compression. To optimize VDU E: you use the following command in which the /O parameter means OPTIMIZE and /V: is following by the drive letter of the target VDU: DCF2PAKR /O /V:E Converting DCF/2 Version 1.1a to Version 1.1b Formats Users with existing VDUs formatted under DCF/2 Version 1.1a should refer to the appropriate appendix for the procedure to follow in order to convert VDUs created using version 1.1a to the format used in version 1.1b. ═══ 7.8. The DCAT (Disk Compression Analysis Tool) ═══ The DCF/2 comes with a powerful, statistical Disk Compression Analysis Tool (DCAT) which allows you to measure file compressibility before moving those files into your DCF/2 virtual disk units. The DCAT in an interactive, OS/2 Presentation Manager application with full online help (F1, or HELP button). To run the DCAT, change to the DCF2 program directory and type: DCAT. ═══ 7.9. Moving Files from Physical to Virtual Space ═══ You can use any of your existing DOS, Windows, or OS/2 program utilities to move, copy, delete, and maintain your DCF/2 VDU files. Using XCOPY and DELETE When using XCOPY to copy files into a VDU, it is recommended that you include the '/f' and '/e' command line switches to insure that the existing file extended attributes are copied from the physical disk unit. See the OS/2 online help for XCOPY for additional switches. Using the Drives Icon The OS/2 DRIVES icon provides you with a powerful Presentation Manager utility which not only copies and moves your files between physical and compressed virtual disk storage, it simultaneously updates your DESKTOP objects so that they reflect the necessary drive letter changes, too! Be aware, when moving program objects, that there may be LIBPATH, PATH, and DPATH references to those program objects which may not be updated. If you have very little physical space available on the host and use the drives icon, be careful. The drives icon move seems to move files in large chunks, first copying and then deleting them from their original location. This can cause you to run out of physical space on the host drive and may cause OS/2 to trap. Go slowly. Hint : Including applications stored on a VDU in the LIBPATH statement in your CONFIG.SYS is somewhat problematic. If the AutoCheck function hasn't completed and your VDUs are not yet available to OS/2, it can cause the system to lock up. The workaround is to create the identical subdirectory on a physical disk unit and move all of the program in questions DLLs to the subdirectory on the PDU. Then change the LIBPATH to point to the subdirectory on the PDU. ═══ 8. VDU Maintenance & Troubleshooting ═══ Because of the auto-checking built into the DCF/2 startup process, you won't normally need to spend a great deal of your time checking your physical and virtual space. o Checking Physical Space o Checking Virtual Space o VDU OPTIMIZE (Recompaction) Utility o Troubleshooting ═══ 8.1. Checking Physical Space ═══ THE CARDINAL RULE FOR VDU MAINTENANCE IS: ALWAYS RUN CHKDSK ON THE PHYSICAL DRIVE FIRST. If you suspect that the VDU's physical or host drive is corrupted, you MUST run CHKDSK (FAT) or CHKDSK /F (HPFS) on the physical drive to prevent damaging the VDU. You will use CHKDSK on FAT-based physical disk units and CHKDSK /F on HPFS-based physical disk units. If you are unfamiliar with this program, please refer to OS/2's online help. ═══ 8.2. Checking Virtual Space ═══ Because a VDU looks physical to OS/2, it requires no special utilities beyond those supplied with OS/2. In this case, that is the CHKDSK program. The program will correct any space allocation errors and remove any corrupted files in the VDU, placing them in the FOUND directory as .CHK files if you so choose. Run CHKDSK /F on your VDUs only after you have CHKDSK'ed the physical or host drive or are absolutely certain that the host drive is "clean." When you startup your system, the DCF/2 does this for you. If you are unfamiliar with this program, please refer to OS/2's online help. ═══ 8.3. VDU OPTIMIZE (Recompaction) Utility ═══ Once a week or as you feel it necessary, run the DCF2PAKR program on each of your VDUs to purge them of deleted space and optimize them. During this process each chunk of data stored in the VDU is recompressed. Generally, you will recover about 10% of the space in the drive. The DCF2INFO file for each VDU reports the both the current compression ratio for the VDU and the estimated compression ratio after the next recompaction. The process involves four steps: The first step zeros out deleted and lost space on the drive. We call this "purging." It does not purge data from your VDU -- only free space. The DCF2 must be running during the purge function. Once the purge function is complete, the second step is to stop the DCF2 -- refer to the Appendix for the command and switch to use. The third step is to optimize the drive. This decompresses and recompresses each chunk of data on your VDU. The fourth step is to restart the DCF2. 1. Purge your VDU of deleted space using the DCF2PAKR command: DCF2PAKR /p /v:x 2. Stop the DCF2 using the DCF2 command: DCF2 /A:Shutdown 3. Optimize your VDU using the DCF2PAKR command: DCF2PAKR /o /v:x 4. Restart the DCF2 using the DCF2 command: DCF2 /A:Startup The commands are executed on an OS/2 window or full screen, from the DCF2 program directory. In the above example, the DCF2PAKR command options are: /p (purge), /v:x (The VDU drive letter to be purged, e.g. VDU X) and /o (optimize). You can create a batch file to purge and optimize your VDU(s) and launch it from OS/2's ALARMS applet or from a package like RELISH for OS/2. Just remember to purge all VDUs, then shutdown the DCF2, and then optimize all VDUs before starting the DCF2 again. For additional information please refer to the first section in the Appendix "DCF/2 Command Reference." ═══ 8.4. Troubleshooting ═══ The first place to look to diagnose the cause of a suspected problem is the logfiles, DCF2ACP.LOG and DCF2VCP.LOG in the root of your boot drive. The prescribed remedy whenever you suspect a problem is to do the following: 1. Run CHKDSK /F:2 on the physical host drive three times. (You may need to do this from floppy.) 2. Run CHKDSK /F:3 on the physical host drive at least one time. (Twice, maybe.) 3. Startup the DCF/2 and repeat steps 1. and 2. for each virtual disk unit. Do not panic if the DCF/2 AutoCheck during startup or CHKDSK /F from an OS/2 command processor report frightening sounding error messages about not finding but attempting to reconstruct the root directory for a virtual drive. Let CHKDSK run and repair any damage. Then run it again and again until it reports no errors. You may have some work to do to rename the FOUND directories and CHECK files, but your VDU will be intact. In extreme cases, it may be necessary to restart or reboot your computer system. We have had instances where it looked as if a drive had been lost only to restart the system and find it still there and intact. If the CHKDSK /F program creates FOUND directories, it may, in its infinite wisdom place a renamed copy of your VDU's DCF2INFO.CMD space management file in one of these FOUND directories. This file may appear to occupy a great deal of space. Find it and delete it. ═══ 9. Appendix ═══ The Appendix contains the following sections: o DCF/2 Command Reference o DCF/2 VDU Optimize Utility o OS/2 System Shutdown Parameters o DCF/2 Monitor Parameters o Converting Version 1.1a to Version 1.1b o Using the DCF/2 and Netware o Hints for Running Your Application from a VDU o Tips & Techniques o Cache Considerations ═══ 9.1. DCF/2 Command Reference ═══ DCF2 Control Program Command Line Parameters ┌────────┬──────────────────────┬────────────────────────────────────────┐ │Command │Parameter │Function │ ├────────┼──────────────────────┼────────────────────────────────────────┤ │DCF2 │/A:STARTUP │Starts the DCF/2 Control Processes. │ │ │ │Makes your VDUs available. │ ├────────┼──────────────────────┼────────────────────────────────────────┤ │DCF2 │/+ │"Shorthand" method to start the DCF/2 │ │ │ │Control Processes. │ ├────────┼──────────────────────┼────────────────────────────────────────┤ │DCF2 │/A:Startup /D │Starts the DCF/2 Control Processes and │ │ │ │says to delete the DCF2INFO.CMD at │ │ │ │startup. Use this option if you run │ │ │ │virus scanning software. It will │ │ │ │eliminate uncecessary scanning time. │ ├────────┼──────────────────────┼────────────────────────────────────────┤ │DCF2 │/A:STATUS │Reports the Status of the DCF/2 Control │ │ │ │Processes (currently running or │ │ │ │currently not running). │ ├────────┼──────────────────────┼────────────────────────────────────────┤ │DCF2 │/A:SHUTDOWN │Stops the DCF2 Control Processes. Your │ │ │ │VDUs are unavailable when you stop the │ │ │ │DCF/2. Use this command before you │ │ │ │OPTIMIZE a VDU or if you need to delete │ │ │ │a VDU. │ ├────────┼──────────────────────┼────────────────────────────────────────┤ │DCF2 │/- │"Shorthand" method to stop the DCF/2 │ │ │ │Control Processes. │ ├────────┼──────────────────────┼────────────────────────────────────────┤ │DCF2 │/V:CREATE /S: /F: │Creates VDU of /S:[size in megabytes] │ │ │ │and /F:[file specification] (The path │ │ │ │and filename for the VDU container │ │ │ │file.) │ ├────────┼──────────────────────┼────────────────────────────────────────┤ │DCF2 │/R:X │Refreshes the DCF2INFO file for VDU "X."│ │ │ │(Wait 15 seconds before typing the next │ │ │ │X:DCF2INFO.) │ └────────┴──────────────────────┴────────────────────────────────────────┘ From an OS/2 window or full screen, you can change to the DCF2 program directory and type DCF2 for a list of DCF/2 Control Program commands and switches. ═══ 9.2. DCF/2 VDU Optimize Utility ═══ Note: If multiple VDUs are to be optimized, purge each VDU BEFORE issuing the command to optimize the VDUs. The DCF2 must be running for the purge operation and must NOT be running for the recompression or optimize operation. DCF2PAKRCommandLineParameters ┌──────────┬────────────────────┬────────────────────────────────────────┐ │Command │Parameter │Function │ ├──────────┼────────────────────┼────────────────────────────────────────┤ │DCF2PAKR │/P /V:X │Purges VDU X, where "X" is the VDU's │ │ │ │drive letter. The DCF2 must be running.│ ├──────────┼────────────────────┼────────────────────────────────────────┤ │DCF2PAKR │/O /V:X │Optimizes VDU X, where "X" is the VDU's │ │ │ │drive letter. Before "optimizing", │ │ │ │shutdown the DCF2. │ └──────────┴────────────────────┴────────────────────────────────────────┘ ═══ 9.3. DCF/2 OS/2 System Shutdown Parameters (SHUTDOWN.EXE) ═══ The SHUTDOWN.EXE includes several optional parameters which you execute from either an OS/2 command processor or you can set using the DCF/2 OS/2 System Shutdown icon's Settings Notebook on your Desktop. These are: Parameter Function /i Interactive shutdown. Prompts you to answer yes/no to cancel shutdown. /n No system shutdown. Shuts down the DCF2ACP only. /t "Thinkpad" or the like. This optional parameter doesn't kill processes, but shuts down the DCF2ACP.EXE and system. /s Single click shutdown. On some systems, this may result in an infinite shutdown loop! /d: Default time in seconds for the Shutdown Countdown. The default is 10 seconds. Increase this number if your do not reach the final C-A-D box at shutdown. /w: Smallest Process ID number (detached processes) in a range of PIDs to "kill" at shutdown. /W: Largest Process ID number (detached processed) in a range of PIDs to "kill" at shutdown. ═══ 9.4. DCF/2 Monitor Parameters (DCF2MON.EXE) ═══ Like the SHUTDOWN.EXE program, DCF2MON.EXE includes optional parameters that can either be used from an OS/2 command line or set using the VDU LED icon's Settings Notebook on your Desktop. These are: Parameter Function /l:X VDU Drive letter for this LED icon. /x: followed by a decimal value. Designates the x coordinate location of the LED icon on your Desktop. /y: followed by a decimal value. Designates the y coordinate location of the LED icon on your Desktop. /t: followed by time in seconds. Establishes the refresh frequency for the LED icon. Increase this if you feel the monitor refreshes are loading your system. (Applies to certain video adaptors.) ═══ 9.5. Converting DCF/2 Version 1.1a VDU's to Version 1.1b ═══ Note: Before you can use DCF/2 Version 1.1a VDU's with Version 1.1b, you must follow the procedure outlined below to "convert" them. 1. Backup your 1.1a VDU before installing the DCF/2 1.1b. 2. Do not use the "Update/Register" option on the installation menu. Do a full install according to the following steps: a. REM out all DCF/2 1.1a statements in your CONFIG.SYS file. b. Rename any existing DCF/2 VDUs to names other than DCF2_X.VDU, (e.g., DCF2_X.11A); so that the install program does not delete it. c. Reboot your computer system. d. Install the DCF/2 Version 1.1b. e. Reboot your computer system (the install program will do this for your). 3. Let the DCF/2 startup normally. 4. Go to an OS/2 command prompt and change to the DCF/2 program directory. 5. Use a SET statement to point to your version 1.1a VDU: SET DCF2_VDU_X=DCF2_X.11a. 6. Stop the DCF/2 using the command, DCF2 /A:SHUTDOWN. 7. Use the DCF2PAKR program to decompress and then recompress the data in the VDU: Type DCF2 /O /V:X, where "X" is the VDU's drive letter. 8. Your Version 1.1a VDU is now reformatted for Version 1.1b usage. Note: The conversion takes approximately 1 minute per 1K chunks of data. Do not interrupt interrupt the DCF2PAKR program or the VDU will be lost. ═══ 9.6. Using the DCF/2 and Netware ═══ If your VDU host is a Netware file server volume, the following tips should be helpful. 1. Run your Netware login from the CONFIG.SYS using "CALL=x:\Netware\login.exe". Place this CALL statement AFTER the block of Netware statements and BEFORE the "CALL=x:\DCF2\DCF2.EXE /A:STARTUP." 2. Shutdown the DCF/2 BEFORE logging out. The login-logout process can be automated using a REXX command procedure like the one that follows. 3. Network-bassed VDUs are not shareable by two or more workstations at the same time. They can be accessed serially. 4. A Netware-based VDU is a good place to keep personal data, but not recommended for storing Netware login, logout and other utilities. Sample REXX Command to Synchronize Login and Logout /* Netware login / logout */ PARSE UPPER SOURCE . . progName progName = FileSpec('Nane',progName) PARSE ARG args /* Shutdown DCF/2 in preparation for logout */ 'd:\dcf2\dcf2.exe /a:shutdown' SELECT WHEN progName = 'LOGIN.CMD' THEN 'd:\netware\login.exe args WHEN progName = 'LOGOUT.CMD' THEN 'd:\netware\logout.exe' OTHERWISE SAY 'Program name must be LOGIN.CMD or LOGOUT.CMD' END /* Startup DCF/2 now that drives have been remapped */ 'd:\dcf2\dcf2 /a:startup' EXIT For initial startup, use the CALL statement in the CONFIG.SYS. Then use the above sample program or one like it for subsequent logins and logouts. You can make two copies of the sample program -- name one LOGIN.CMD and the other LOGOUT.CMD. You may need to copy the login.exe and logout.exe programs to a local drive. ═══ 9.7. Hints for Running Your Applications from a VDU ═══ Each application you run has a personality and quirks all its own. We have tested a wide variety of DOS, Windows and OS/2 applications. For most of them, the transition from physical to virtual is effortless. They run from a virtual drive just as they did from a physical one. The following is a collection of hints contributed by DCF/2 testers, based on their experiences with some of the more finicky applications. AmiPro 3.0a AmiPro style sheets seem to want to load from a physical disk. Not allowing them to do so can result in a SYS3175 error. Workaround: Move all of AmiPro to the VDU, but make sure that the style sheet directory is on a physical disk. Then modify AMIUSER3.INI (use AmiPro's INIEDIT.EXE), so that the INI entry for the style sheet directory points to the right place. FaxWorks The FaxWorks device driver loads before the DCF/2 starts up. As a result, if it is on a VDU, the device is not found. Workaround: Load FaxWorks FMD.SYS from a physical drive. Communications Manager/2 If Communications Manager/2 (and any number of other programs which add statements to your CONFIG.SYS) is installed after the DCF/2, edit your CONFIG.SYS so that the last statement in the file is the CALL=x:\DCF2\DCF2.EXE /A:STARTUP. In the case of Communications Manager/2, this will preclude its startup process from interferring with that of your VDUs. ═══ 9.8. Tips & Techniques ═══ The following tips and techniques for using the DCF/2 were contributed by DCF/2 beta testers. Maintenance Partition While you may never need one, should "disaster strike" (DCF/2 or otherwise), you won't regret time you spent creating a small -- 3MB, for example -- maintenance partition. Include on your maintenance partition a small editor should you need it to edit your CONFIG.SYS. Also include CHKDSK.COM, UHPFS.DLL and HPFS.IFS (make sure these are the versions currently in use on your system), so that CHKDSK exercises on the "normal" partition can be performed. If you have access to CompuServe, you may want to download BOOTOS.ZIP from OS2USER, Library 17 (also EWS). The file is intended for those in need of a bit of assistance when creating a maintenance partition. Devices that Load in the CONFIG.SYS Device drivers which are loaded during the processing of the CONFIG.SYS prior to the DCF2PDD.SYS, should not be stored on a VDU. Read/Write or Magneto Optical Drives In the event of an improper shutdown (loss of power, trap, hang, etc.) for the case in which the VDU host is an Read/Write or Magneto Optical, do the following: 1. Take the media out of the drive on startup. 2. Let the DCF/2 AutoCheck run. 3. From an OS/2 Command Processor, change to the DCF2 program directory and shutdown the DCF2ACP. Use the command, DCF2 /- or DCF2 /A:SHUTDOWN. 4. Put the media in the drive and do CHKDSK /F on the physical media. 5. From an OS/2 Command Processor, change to the DCF2 program directory and startup the DCF2ACP. Use the command, DCF2 /+ or DCF2 /A:STARTUP. 6. Let the DCF/2 AutoCheck run. ═══ 9.9. Cache Considerations ═══ Select from the tables below based upon whether your system is HPFS-only, FAT-only, Both with HPFS Active and FAT Passive or Both with HPFS Passive and FAT Active. For our purposes, "active" and "passive" are descriptors for the way a partition is used. If it is seldom used, consider it "passive." If a lot of disk intensive I/O occurs on the partition, consider it "active." Case 1: HPFS Partitions Only ┌──────┬──────┬──────────┬────────┬──────────┬──────────┬────────────────────┐ │RAM │CACHE │LAZY │MAXAGE │DISKIDLE │BUFFERIDLE│Other │ │ │ │WRITES │ │ │ │ │ ├──────┼──────┼──────────┼────────┼──────────┼──────────┼────────────────────┤ │16MB │2048 │/LAZY:on │40000 │30000 │20000 │REM out DISKCACHE │ │ │ │ │ │ │ │statement │ ├──────┼──────┼──────────┼────────┼──────────┼──────────┼────────────────────┤ │12MB │1536 │Same │Same │Same │Same │Same │ ├──────┼──────┼──────────┼────────┼──────────┼──────────┼────────────────────┤ │8MB │1024 │Same │Same │Same │Same │Same │ └──────┴──────┴──────────┴────────┴──────────┴──────────┴────────────────────┘ Case 2: FAT Partitions Only ┌──────┬──────┬──────────┬────────────────────────────────────────────────┐ │RAM │CACHE │LAZY │Other │ │ │ │WRITES │ │ ├──────┼──────┼──────────┼────────────────────────────────────────────────┤ │16MB │2048 │/LW │REM out the HPFS.IFS statement │ ├──────┼──────┼──────────┼────────────────────────────────────────────────┤ │12MB │1536 │Same │Same │ ├──────┼──────┼──────────┼────────────────────────────────────────────────┤ │8MB │1024 │Same │Same │ └──────┴──────┴──────────┴────────────────────────────────────────────────┘ Case 3: HPFS and FAT with HPFS Active ┌──────┬──────┬──────────┬────────┬──────────┬──────────┬────────────────────┐ │RAM │CACHE │LAZY │MAXAGE │DISKIDLE │BUFFERIDLE│DISKCACHE │ │ │ │WRITES │ │ │ │ │ ├──────┼──────┼──────────┼────────┼──────────┼──────────┼────────────────────┤ │16MB │2048 │/LAZY:on │40000 │30000 │20000 │512-1024 │ ├──────┼──────┼──────────┼────────┼──────────┼──────────┼────────────────────┤ │12MB │1536 │Same │Same │Same │Same │256-512 │ ├──────┼──────┼──────────┼────────┼──────────┼──────────┼────────────────────┤ │8MB │1024 │Same │Same │Same │Same │128-256 │ └──────┴──────┴──────────┴────────┴──────────┴──────────┴────────────────────┘ Case 4: HPFS and FAT with FAT Active ┌──────┬──────┬──────────┬────────┬──────────┬──────────┬──────────┬──────────┐ │RAM │CACHE │HPFS LAZY │MAXAGE │DISKIDLE │BUFFERIDLE│DISKCACHE │FAT LAZY │ │ │ │WRITES │ │ │ │ │WRITES │ ├──────┼──────┼──────────┼────────┼──────────┼──────────┼──────────┼──────────┤ │16MB │1024 │N/A │40000 │30000 │20000 │2048 │/LW │ ├──────┼──────┼──────────┼────────┼──────────┼──────────┼──────────┼──────────┤ │12MB │768 │Same │Same │Same │Same │1536 │Same │ ├──────┼──────┼──────────┼────────┼──────────┼──────────┼──────────┼──────────┤ │8MB │512 │Same │Same │Same │Same │1024 │Same │ └──────┴──────┴──────────┴────────┴──────────┴──────────┴──────────┴──────────┘ Based upon the file system and cache tuning testing, the following are true: o The HPFS actually requires 128 to 130K of committed memory -- as opposed to the widely perceived 512K. As cache size increases to 2MB (2048), this requirement increases as well, up to a maximum of about 240K. o The optimal cache size seems to be 1536. o When comparing the relative merits of the HPFS versus FAT, consider the following: On partitions of identical size, the HPFS gives you about 15% more space and performance is about 28% better! o Instead of continuing to increase performance, a DISKCACHE value in excess of 2048 seems to degrade performance rather than improve it. ═══ 10. Glossary of Terms ═══ The glossary provides definitions for commonly used terms. On-the-fly Data Compression An on-the-fly data compression product creates a special file, which serves as a container for compressed data. When the an application requests data stored in this way, the data is automatically compressed or decompressed "on-the-fly." The user does not have to execute a command to "unzip" or "unpak" the data requested. Virtual Disk Unit or VDU "Virtual Disk Unit" is the term we use to describe a DCF/2 compressed drive. It looks like a "real" or "physical" drive to OS/2. Target Drive The target drive is the uncompressed drive to which the DCF/2 program files are copied during the installation and from which OS/2 runs DCF/2 programs. Host Drive The host drive is the physical drive on which a DCF/2 "Virtual Disk Unit" or VDU resides. DCF/2 Ancillary Control Process (DCF2ACP) Just as a physical disk unit has a controller, so do our virtual disks. The "ACP" is the virtual disk's controller. When the DCF2ACP is stopped, it is analogous to pulling your physical disk's controller out of your system box. You cannot access compressed data on a VDU if the DCF2ACP is not running. DCF/2 VDU Control Process (DCF2VCP) The DCF2VCP manages the virtual disk units you create using the controller (DCF2ACP). DCF/2 Space Manager One of the most important functions of the VDU Control Process (DCF2VCP) is space management for each of your VDUs. DCF2VCP monitors the amount of space available on each VDU's host drive and prevents the VDU from running out physical space. "Dirty" The term "dirty" is used to describe the state of a physical or virtual drive when the drive was shutdown by a means other than running the DCF/2 shutdown program. Typically, this happens if you switch off the computer without running shutdown first. It can happen as the result of a power failure or brownout. It can also happen as the result of an operating system trap or hang. A drive that is "dirty" must be CHKDSKed prior to its being available for use.